home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c
- Path: uu4news.netcom.com!friend!news
- From: rich@kastle.com (Richard Krehbiel)
- Subject: Re: realloc(NULL,100)
- Message-ID: <1996Mar4.122207.16986@friend.kastle.com>
- Sender: news@friend.kastle.com (News)
- Reply-To: rich@kastle.com
- Organization: Kastle Development Associates
- X-Newsreader: Forte Free Agent 1.0.82
- References: <31346CB0.41C67EA6@jupiter.di.uminho.pt> <TANMOY.96Feb28151825@qcd.lanl.gov>
- Date: Mon, 4 Mar 1996 12:23:15 GMT
-
- tanmoy@qcd.lanl.gov (Tanmoy Bhattacharya) wrote:
-
- >Except for the undefined behaviour, returning null or a valid address
- >are both correct behaviours. Crashing is not.
-
- Let me just offer a "corrected" program (hopefully free of standards
- violations):
-
- #include <stdio.h>
- #include <stdlib.h>
-
- int main(void)
- {
- void *p = realloc(NULL, 100);
- printf("%p\n", p);
- return 0;
- }
-
- The original poster said that he got NULL under some environments.
- Several replies pointed out that it is legal and valid for this small
- program to indicate a NULL result. Sure, it's a valid result, any
- malloc() call may fail. But I would be shocked to hear that I should
- reasonably expect the above to show NULL. The hosted environment that
- does so is either broken or limited unto uselessness.
-
- I'm sure the standard says nothing (and it can say nothing) about
- exactly how much dynamic memory might be available to an executing
- program. Perhaps the answer to "how much memory is available" is
- different from instant to instant, for reasons not under the program's
- control, due to the environment serving memory resources to several
- concurrently executing programs. So from a strictly standards-
- guaranteed standpoint, the more robust program should avoid malloc
- entirely, because there's no guarantee that malloc will ever return
- anything besides NULL. (I have a suspicion that every useful C
- program is at least implementation-defined, if not undefined, by
- strict interpretation of the standard.)
-
- Something else I wonder; is it valid for realloc(NULL, 100) to fail
- (return NULL) in circumstances that malloc(100) would not? Are the
- mechanics of memory allocation so implementation-defined that it's not
- possible to say? Hm. Probably.
-
- Tell me how silly the following is:
-
- #include <stdio.h>
- #include <stdlib.h>
-
- int main(void)
- {
- void *p;
- char *source;
-
- if((p = realloc(NULL, 100)) == NULL)
- {
- /* realloc failed, try malloc */
- p = malloc(100);
- source = "malloc"; /* Say the memory came from malloc */
- }
- else
- {
- source = "realloc"; /* Say the memory came from realloc */
- }
-
- if(p)
- printf("Succeed, %s\n", source);
- else
- printf("Fail, %s\n", source);
-
- return 0;
- }
-
-
- Similarly silly:
-
- #include <stdio.h>
- #include <stdlib.h>
-
- int main(void)
- {
- void *p;
- int i;
-
- /* Try really hard, up to 100 times, to get the memory
- I desparately need */
- for(i = 0, p = NULL; p != NULL && i < 100; i++)
- p = malloc(100);
-
- return p ? EXIT_SUCCESS : EXIT_FAILURE;
- }
-
- Sheesh. Now I'm fumed. By the standard's grace, none of my programs
- that use malloc may be expected to do a damned thing.
-
- --
- Richard Krehbiel, Kastle Systems, Arlington VA USA
- rich@kastle.com (work) or richk@mnsinc.com (personal)
-
-